Optical control plane implementations provide automated setup and control of services. Advantageously, control planes offer multi-vendor and inter-domain inter-working, enhanced service offerings such as Ethernet over SONET/SDH or Optical Transport Network (OTN), end-to-end service activation, cross-domain provisioning of switched connection services, and the like. Traditionally, creating traffic paths through a series of Network Elements (NEs) has involved configuration of individual cross-connects on each NE. Control planes allow a user to specify the start point, end point, and bandwidth required, and an agent on the Network Elements allocates a path through the network, provisioning the traffic path, setting up cross-connects, and allocating bandwidth from the paths for the user requested service. The actual path that the traffic will take through the network is not specified by the user.
Several control plane standards exist including ITU-T Automatically Switched Optical Network (ASON), IETF Generalized Multi-Protocol Label Switching (G-MPLS) also known as Automatic Switched Transport Network (ASTN), and Optical Internetworking Forum (OIF) User-Network Interface Signaling Specifications (UNI) and Inter-Carrier Network Interface Signaling Specification. ASON specifications generally define an optical control plane communication framework. G-MPLS defines control plane discovery, routing, and signaling protocols. OIF UNI/E-NNI specifications define protocol extensions for multi-vendor interoperability.
OIF defines an Optical User to Network Interface (O-UNI) for an interface between a client network and an optical network. This further includes signaling and SPC connection creation, deletion, query, and the like, and does not provide topology information exchanged between client and network. OIF also defines an External Network Node Interface (E-NNI) between optical networks and between areas within a single network. This provides signaling for connection establishment, removal, restoration, and the like. Advantageously, E-NNI and O-UNI provide interoperability of intelligent optical networks with control plane messaging. For example, an ASON network can be compartmentalized into multiple independent control domains. The E-NNI interfaces provide interoperability between the multiple independent control domains.
Referring to FIG. 1, in an ASON network 10, connections can be requested originally from either a client device 12a,12b (in which case it is called a switched connection (SC) 14) or a management system interface 16 (in which case it is called a soft permanent connection (SPC) 18). In this exemplary embodiment, the ASON network 10 includes three control domains: domain A 20, domain B 22, and domain C 24, and six network elements (NEs) 30,32,34,36,38,40. The requesting entity can be part of any control domain 20,22,24 or part of an exterior network.
Domain A 20 includes NEs 30,32 as border nodes (BNs). Domain B 22 includes NEs 34, 36 as BNs, and domain C 24 includes NEs 38,40 as BNs. Each of the domains 20,22,24 can include other NEs in-between the BNs (not shown), and these are referred to as interior nodes (INs). In this exemplary embodiment, clients 12a,12b connect to NEs 30,40, respectively, using an O-UNI connection. This allows for control plane interoperability between the clients 12a,12b and the domains 20,22,24. The domains 20,22,24 interconnect with E-NNI interfaces between NEs 32 and 34 for interconnection of domain A 20 and domain B 22 and between NEs 36 and 38 for interconnection of domain B 22 and domain C 24.
Sub Network connections (SNC) 42,44,46 originate across one border node of a network (i.e., domain 20,22,24) and terminate on another border node across the same network (i.e., domain 20,22,24). In FIG. 1, SNC 42 originates from NE 30 and terminates on NE 32, SNC 44 originates on NE 34 and terminates on NE 36, and SNC 46 originates from NE 38 and terminates on NE 40. The links between NEs 32 and 34, 36 and 38 are E-NNI links. The end NEs 30,40 across the domains 20,22,24 could be SC clients that originate and terminate the SC connection 14. So, typically an SC or SPC connection can include multiple SNC connections. Also, the connections 14,18 could include SONET/SDH services or Ethernet resources. In the case of an Ethernet connection request, the connection has to be created in a multi layer fashion with PATH Messages for Ethernet, Virtual Concatenation (VCAT), and SONET/SDH layer. For the Ethernet connection, only ingress and egress network end nodes are aware of Ethernet and VCAT layers, and all other nodes are just SONET layer aware.
To set up connections, the ASON network 10 performs a path computation to build Explicit Route Objects (EROs) for a connection. The path computation utilizes different traffic parameters, such as protection types, service classes, cost of abstract and E-NNI links, and the like, to find a lowest cost path. Note the path computation can be used to set up any connection type (e.g. SONET/SDH, Ethernet, or the like). Disadvantageously, path computation and ASON database mechanism do not currently exist for ASON networks. With regard to building the ASON Database, this information is never persisted and is discovered dynamically each time and updated whenever the topology is changed (added/modified/deleted). All Domains except the internal domain are treated as remote domains. If there is a mismatch in any link configuration, such links are disregarded for path computation resulting in easy diagnosis for the operator to find misconfigurations.
Also, the current standards talk about setting up of multi-layer connections in a broader sense. Disadvantageously, current standards do not specify how to achieve hitless connection setups, mesh restoration, and how to bundle the connections under VCAT layer and route them as well as the behavior during mesh restoration. Also note that at higher layers Ethernet and VCAT, there is no physical resource that is tied and hence there should be a virtual resource that should be available to keep the connection active. The connection at Ethernet Layer should be able to create and delete VCGs dynamically in the ASON Networks whenever the connection is serviced.
In GMPLS world, when two nodes conflict on a resource while setting up the connection, a PATH message carries label Set or explicit label information for negotiation to its down stream node. Later, based on the label information in RESV message sent from the down stream node, upstream node selects a label (Resource) based on availability at its side, else rejects this request. In networks where each network supports a single node it is easy to establish label negotiation supporting above scenario where the cross connects could be created when RESV is received and the resource is available. In scenarios where the network includes a large number of nodes and the connection has to traverse across many nodes through in-band communication and connection setup is done at the border node of the network, it is hard for such a label negotiation to succeed and currently there is no mechanism to support that for a originating node to create such connections.
The current approach visualizes border node which receives the incoming request to create a subtended node connection (SNC) to terminate on a virtual connection point (VCP) which is a logical entity created by this connection at the terminating border node. At this point the PATH message is forwarded to the next domain. Later after receiving the RESV message from down stream node, based on the resource availability (for the label passed in RESV message) cross connect is created with the new resource and this logical entity and the RESV message is forwarded to the originating border node via in-band communication. Such a connection is also supported to recover from persistence across reboots. The existing architectures fail here because an SNC can resolve its resources internally in the I-NNI domain but when it comes to reserve the resource at border node, it is hard to identify the label. For example, as in a typical telecom network, this timeslot/bandwidth (resource) may be in use by other node across the E-NNI link.